Frontend am Edge: Ein tiefer Einblick in Cloudflare Workers und AWS Lambda@Edge

Im unermüdlichen Streben nach schnelleren, sichereren und hochgradig personalisierten Benutzererlebnissen durchläuft die Architektur des Webs eine tiefgreifende Transformation. Jahrelang war das Modell einfach: ein zentraler Server, ein Content Delivery Network (CDN) zum Cachen statischer Assets und ein Client. Doch da Anwendungen immer komplexer werden und die Erwartungen der Benutzer an sofortige Interaktionen steigen, stößt dieses traditionelle Modell an seine Grenzen. Willkommen im Zeitalter des Edge Computing – ein Paradigmenwechsel, der Berechnungen und Logik von entfernten Cloud-Servern an den Netzwerkrand verlagert, nur Millisekunden vom Endbenutzer entfernt.

Für Frontend-Entwickler und Architekten ist dies nicht nur ein weiterer Backend-Trend. Es stellt eine fundamentale Veränderung in der Art und Weise dar, wie wir Webanwendungen erstellen, bereitstellen und ausliefern. Es verleiht dem Frontend Fähigkeiten, die zuvor dem Server vorbehalten waren, verwischt die Grenzen und eröffnet ein beispielloses Potenzial. In dieser globalen Arena haben sich zwei Titanen als Spitzenreiter herauskristallisiert: Cloudflare Workers und AWS Lambda@Edge. Dieser Leitfaden bietet eine umfassende Untersuchung beider Plattformen, um Ihnen zu helfen, ihre Kernprinzipien zu verstehen, ihre Stärken und Schwächen zu vergleichen und zu entscheiden, welche die richtige für Ihr nächstes globales Projekt ist.

Was ist Frontend Edge Computing? Vom CDN zum programmierbaren Edge

Um die Bedeutung von Edge Computing zu verstehen, ist es wichtig, seine Entwicklung nachzuvollziehen. Im Kern bezieht sich der „Edge“ auf das globale Netzwerk von Servern (Points of Presence oder PoPs), die sich zwischen dem Ursprungsserver Ihrer Anwendung und Ihren Benutzern befinden. Traditionell wurden diese Server von CDNs für einen einzigen Hauptzweck verwendet: Caching.

Die Evolution: Mehr als nur Caching

CDNs revolutionierten die Web-Performance, indem sie Kopien statischer Assets wie Bilder, CSS- und JavaScript-Dateien in PoPs auf der ganzen Welt speicherten. Wenn ein Benutzer in Tokio eine Datei anforderte, wurde sie von einem nahegelegenen Server in Japan ausgeliefert, anstatt eine lange, latenzreiche Reise zu einem Ursprungsserver in Nordamerika zu unternehmen. Dies reduzierte die Ladezeiten dramatisch.

Dieses Modell war jedoch auf statische Inhalte beschränkt. Jede dynamische Logik – wie die Personalisierung von Inhalten, die Authentifizierung eines Benutzers oder die Durchführung eines A/B-Tests – erforderte immer noch einen Roundtrip zum Ursprungsserver. Dieser Roundtrip führte zu Latenz, dem erklärten Feind einer guten Benutzererfahrung.

Edge Computing sprengt diese Einschränkung. Es macht das Edge-Netzwerk des CDN programmierbar. Anstatt nur statische Dateien zu cachen, können Entwickler jetzt benutzerdefinierten Code direkt auf diesen Edge-Servern bereitstellen und ausführen. Das bedeutet, dass dynamische Logik im PoP ausgeführt werden kann, der dem Benutzer am nächsten ist, um Anfragen abzufangen und Antworten im laufenden Betrieb zu ändern, ohne für viele Aufgaben jemals den Ursprungsserver kontaktieren zu müssen.

Warum ist das für das Frontend wichtig?

Die Verlagerung von Logik an den Edge hat massive Auswirkungen auf die Frontend-Entwicklung und die Anwendungsleistung. Die Vorteile sind erheblich:

• Drastisch reduzierte Latenz: Durch die Ausführung von Code näher am Benutzer eliminieren Sie die Roundtrip-Zeit zu einem zentralen Server. Dies führt zu schnelleren API-Antworten, kürzeren Seitenladezeiten und einer bissigeren, reaktionsschnelleren Benutzeroberfläche.
• Verbesserte Leistung: Aufgaben wie A/B-Tests, Feature-Flagging und Routing können am Edge erledigt werden. Dies entlastet sowohl den Browser des Clients als auch den Ursprungsserver und verbessert die Leistung auf der ganzen Linie.
• Globale Skalierbarkeit standardmäßig: Edge-Funktionen werden über das gesamte globale Netzwerk eines Anbieters bereitgestellt. Ihre Anwendung wird automatisch skaliert und ist widerstandsfähig, sodass sie Verkehrsspitzen von überall auf der Welt ohne manuellen Eingriff bewältigen kann.
• Verbesserte Sicherheit: Sie können sicherheitsrelevante Aufgaben wie die Authentifizierung von Tokens (z. B. JWTs), das Blockieren bösartiger Anfragen oder die Durchsetzung von Zugriffskontrollen am Edge erledigen, bevor eine Anfrage jemals Ihre Ursprungsinfrastruktur erreicht. Dies schafft einen leistungsstarken, verteilten Sicherheitsperimeter.
• Kosteneffizienz: Die Entlastung Ihrer Ursprungsserver von Anfragen kann deren Last erheblich reduzieren, was zu niedrigeren Infrastrukturkosten führt. Darüber hinaus sind die serverlosen Preismodelle von Edge-Plattformen oft sehr kostengünstig.
• Leistungsstarke Personalisierung: Sie können HTML modifizieren, Inhalte basierend auf Geografie oder Benutzer-Cookies personalisieren und verschiedenen Benutzersegmenten unterschiedliche Erlebnisse bieten – alles mit minimaler Latenz.

Cloudflare Workers: Die V8 Isolate Revolution

Cloudflare, ein langjähriger Marktführer im CDN- und Sicherheitsbereich, hat mit Cloudflare Workers eine wegweisende Plattform in der Welt des serverlosen Edge Computing auf den Markt gebracht. Ihre Kerninnovation liegt nicht nur darin, wo der Code ausgeführt wird, sondern wie er ausgeführt wird.

Was sind Cloudflare Workers?

Mit Cloudflare Workers können Sie JavaScript und WebAssembly (Wasm) im riesigen globalen Netzwerk von Cloudflare ausführen, das Hunderte von Städten in über 100 Ländern umfasst. Ein Worker ist im Wesentlichen ein Stück Code, das HTTP-Anfragen abfängt und verarbeitet. Er kann Anfragen ändern, bevor sie Ihren Ursprung erreichen, Antworten direkt vom Edge generieren oder Inhalte aus mehreren Quellen streamen.

Die Entwicklererfahrung ist so gestaltet, dass sie vertraut ist und eine Service Worker-ähnliche API verwendet. Wenn Sie jemals einen Service Worker für einen Webbrowser geschrieben haben, wird Ihnen das Programmiermodell intuitiv vorkommen.

Die Magie der V8 Isolates

Das wahre Genie hinter der Leistung von Cloudflare Workers ist die Verwendung von V8 Isolates anstelle von traditionellen Containern oder virtuellen Maschinen (VMs). V8 ist dieselbe hochleistungsfähige JavaScript-Engine, die auch Google Chrome und Node.js antreibt.

Ein Isolate ist ein leichtgewichtiger Kontext, der Variablen mit dem Code gruppiert, der auf sie einwirkt. Mehrere Isolates können innerhalb eines einzigen Betriebssystemprozesses ausgeführt werden, sind aber vollständig voneinander getrennt. Dies hat tiefgreifende Auswirkungen:

• Nahezu null Kaltstarts: Ein neues Isolate kann in weniger als 5 Millisekunden gestartet werden. Das ist um Größenordnungen schneller als die Sekunden, die es dauern kann, einen neuen Container für eine traditionelle serverlose Funktion hochzufahren. Für Benutzer bedeutet dies, dass Kaltstarts praktisch nicht existieren und jede Anfrage schnell ist.
• Massive Skalierbarkeit und Effizienz: Isolates sind unglaublich leichtgewichtig und verbrauchen deutlich weniger Speicher als Container. Dies ermöglicht es Cloudflare, Tausende von Worker-Skripten auf einer einzigen physischen Maschine auszuführen, was die Plattform hocheffizient und kostengünstig macht.
• Verbesserte Sicherheit: Die Sandbox-Natur von V8 Isolates bietet starke Sicherheitsgrenzen, die verhindern, dass ein Worker einen anderen beeinträchtigt.

Praktische Anwendungsfälle mit Codebeispielen

Cloudflare Workers sind unglaublich vielseitig. Lassen Sie uns einige gängige Anwendungsfälle untersuchen.

A/B-Testing am Edge

Sie können Benutzer zu verschiedenen Versionen Ihrer Website leiten, ohne clientseitiges JavaScript-Flackern oder komplexe Backend-Logik. Der Worker inspiziert ein eingehendes Cookie und schreibt die URL um, um Inhalte von einem anderen Ursprung oder Pfad abzurufen.

            
// Example: A/B Testing Worker

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const AB_COOKIE = 'ab-test-variant'
  const cookie = request.headers.get('cookie')

  // Determine which variant to show
  let group = 'control'
  if (cookie && cookie.includes(`${AB_COOKIE}=treatment`)) {
    group = 'treatment'
  }

  let url = new URL(request.url)

  // If the user is in the treatment group, fetch the alternative page
  if (group === 'treatment') {
    url.pathname = '/treatment' + url.pathname
  }

  // Fetch the appropriate version
  return fetch(url, request)
}

            

              
                Copy
              
            
          

Dynamische URL-Umschreibungen und Weiterleitungen

Behalten Sie saubere URLs für Benutzer bei, während Sie sie auf eine andere Backend-Struktur abbilden, oder führen Sie SEO-freundliche Weiterleitungen nach einer Website-Migration durch.

            
// Example: Dynamic Redirect Worker

const redirectMap = new Map([
  ['/old-about-us', '/about'],
  ['/products/old-product', '/products/new-product']
])

addEventListener('fetch', event => {
  const url = new URL(event.request.url)
  const { pathname } = url

  const destinationURL = redirectMap.get(pathname)

  if (destinationURL) {
    return Response.redirect(url.origin + destinationURL, 301)
  }

  // No redirect needed, proceed as normal
  return fetch(event.request)
})

            

              
                Copy
              
            
          

Authentifizierung und Autorisierung am Edge

Schützen Sie Ihre gesamte Anwendung oder bestimmte Routen, indem Sie ein JSON Web Token (JWT) am Edge validieren. Ungültige Anfragen werden abgelehnt, bevor sie jemals Ursprungsressourcen verbrauchen können.

            
// Conceptual Example: JWT Validation Worker
// Note: This requires a JWT library compatible with Workers

import { verify } from 'jwt-library'; // Placeholder for a real library

const JWT_SECRET = 'your-super-secret-key';

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const authHeader = request.headers.get('Authorization')

  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return new Response('Unauthorized', { status: 401 })
  }

  const token = authHeader.substring(7)

  try {
    // Verify the token at the edge
    await verify(token, JWT_SECRET)
    // If valid, proxy the request to the origin
    return fetch(request)
  } catch (error) {
    // If invalid, reject the request
    return new Response('Invalid token', { status: 403 })
  }
}

            

              
                Copy
              
            
          

AWS Lambda@Edge: Erweiterung von CloudFront mit Serverless-Power

Amazon Web Services (AWS) bietet mit Lambda@Edge eine eigene leistungsstarke Lösung für Edge Computing an. Es ist kein eigenständiges Produkt, sondern eine Funktion von Amazon CloudFront, seinem globalen CDN. Lambda@Edge ermöglicht es Ihnen, AWS Lambda-Funktionen als Reaktion auf CloudFront-Ereignisse auszuführen und so die Leistungsfähigkeit und Vertrautheit des AWS-Ökosystems an den Edge zu bringen.

Was ist Lambda@Edge?

Mit Lambda@Edge können Sie Node.js- und Python-Code an AWS-Edge-Standorten weltweit ausführen. Anstatt durch ein API-Gateway oder ein S3-Ereignis ausgelöst zu werden, werden diese Funktionen durch den Lebenszyklus einer Anfrage ausgelöst, während sie durch CloudFront läuft. Diese enge Integration ist sowohl ihre größte Stärke als auch ein wesentliches Unterscheidungsmerkmal zu Cloudflare Workers.

Im Gegensatz zu Cloudflare Workers, die auf jedem PoP laufen, werden Lambda@Edge-Funktionen in den regionalen Edge-Caches von AWS bereitgestellt, die eine kleinere, zentralere Gruppe von Standorten als die vollständige Menge der CloudFront-PoPs darstellen. Dies ist ein entscheidender architektonischer Unterschied mit Auswirkungen auf die Leistung.

Die vier Ereignis-Trigger verstehen

Die Funktionalität von Lambda@Edge wird durch vier verschiedene Ereignis-Trigger definiert, an die Sie Ihre Funktion anhängen können. Diese zu verstehen ist der Schlüssel zur effektiven Nutzung des Dienstes.

• Viewer Request: Dieser Trigger wird ausgelöst, nachdem CloudFront eine Anfrage von einem Betrachter (Benutzer) erhalten hat, aber bevor es seinen Cache überprüft. Er ist ideal für Aufgaben, die bei jeder einzelnen Anfrage ausgeführt werden müssen, wie Weiterleitungen, Header-Manipulation oder Cookie-basierte Personalisierung.
• Origin Request: Dieser Trigger wird nur ausgelöst, wenn der angeforderte Inhalt nicht im CloudFront-Cache ist (ein Cache-Miss). Die Funktion wird ausgeführt, kurz bevor CloudFront die Anfrage an Ihren Ursprungsserver (z. B. einen S3-Bucket oder eine EC2-Instanz) weiterleitet. Er ist perfekt für komplexe URL-Umschreibungen, dynamische Ursprungsauswahl oder das Hinzufügen von Authentifizierungs-Headern, die nur der Ursprung sehen muss.
• Origin Response: Dieser Trigger wird ausgelöst, nachdem CloudFront eine Antwort vom Ursprung erhalten hat, aber bevor es diese Antwort zwischenspeichert. Sie können ihn verwenden, um die Antwort des Ursprungs zu ändern, z. B. durch Hinzufügen von Sicherheits-Headern, Größenänderung von Bildern oder Verbergen ursprungsspezifischer Header.
• Viewer Response: Dieser Trigger wird kurz bevor CloudFront die endgültige Antwort an den Betrachter zurücksendet ausgelöst, unabhängig davon, ob es sich um einen Cache-Treffer oder -Fehlschlag handelte. Er ist nützlich, um Header hinzuzufügen, die der Browser benötigt, wie CORS- oder HSTS-Header, oder um endgültige Antwortdaten zu protokollieren.

Praktische Anwendungsfälle mit Codebeispielen

Schauen wir uns an, wie man gängige Probleme mit dem Trigger-basierten Modell von Lambda@Edge lösen kann.

Anpassen von Headern für Sicherheit und Caching

Verwenden Sie einen Viewer Response-Trigger, um wichtige Sicherheits-Header wie `Strict-Transport-Security` zu jeder an den Benutzer ausgelieferten Antwort hinzuzufügen.

            
// Example: Add Security Headers (Viewer Response)

'use strict';

exports.handler = (event, context, callback) => {
    const response = event.Records[0].cf.response;
    const headers = response.headers;

    headers['strict-transport-security'] = [{ key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains; preload' }];
    headers['x-content-type-options'] = [{ key: 'X-Content-Type-Options', value: 'nosniff' }];
    headers['x-frame-options'] = [{ key: 'X-Frame-Options', value: 'DENY' }];
    headers['x-xss-protection'] = [{ key: 'X-XSS-Protection', value: '1; mode=block' }];

    callback(null, response);
};

            

              
                Copy
              
            
          

Gerätespezifische Inhaltsauslieferung

Mit einem Viewer Request-Trigger können Sie den `User-Agent`-Header überprüfen, um mobile Benutzer auf eine dedizierte mobile Website umzuleiten oder die URL umzuschreiben, um eine mobil-optimierte Version des Inhalts abzurufen.

            
// Example: Mobile Redirect (Viewer Request)

'use strict';

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;

    const userAgent = headers['user-agent'] ? headers['user-agent'][0].value : '';
    const isMobile = userAgent.includes('Mobile') || userAgent.includes('Android');

    if (isMobile) {
        const response = {
            status: '302',
            statusDescription: 'Found',
            headers: {
                'location': [{ key: 'Location', value: 'https://m.yourwebsite.com' + request.uri }]
            }
        };
        callback(null, response);
        return;
    }

    // Continue with the original request for non-mobile users
    callback(null, request);
};

            

              
                Copy
              
            
          

Schutz Ihres Ursprungs durch Zugriffskontrolle

Mit einem Origin Request-Trigger können Sie einen geheimen Header injizieren, bevor Sie die Anfrage an Ihren Ursprung weiterleiten. Ihr Ursprung kann dann so konfiguriert werden, dass er nur Anfragen akzeptiert, die diesen geheimen Header enthalten, um zu verhindern, dass jemand CloudFront umgeht.

            
// Example: Adding a Secret Header to Origin Requests (Origin Request)

'use strict';

const SECRET_HEADER_VALUE = 'your-very-secret-value';

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;

    // Add a secret header
    request.headers['x-origin-secret'] = [{ key: 'X-Origin-Secret', value: SECRET_HEADER_VALUE }];

    // Forward the modified request to the origin
    callback(null, request);
};

            

              
                Copy
              
            
          

Direkter Vergleich: Cloudflare Workers vs. AWS Lambda@Edge

Beide Plattformen sind unglaublich leistungsstark, basieren aber auf unterschiedlichen Philosophien und Architekturen. Die Wahl zwischen ihnen erfordert einen sorgfältigen Vergleich ihrer Hauptmerkmale.

Wichtige Erkenntnisse aus dem Vergleich:

• Für reine Leistung und niedrigste Latenz hat Cloudflare Workers die Nase vorn aufgrund seiner V8 Isolate-Architektur und seines riesigen Netzwerks von PoPs. Das Fehlen von Kaltstarts ist ein erheblicher Vorteil für benutzerorientierte Anwendungen.
• Für eine tiefe Integration in einen bestehenden AWS-Stack ist Lambda@Edge die natürliche Wahl. Es nutzt vertraute AWS-Konzepte wie IAM und integriert sich nahtlos in CloudFront, S3 und andere Dienste.
• Die Entwicklererfahrung wird oft als große Stärke von Cloudflare Workers genannt. Das Wrangler CLI, schnelle Bereitstellungen und eine einfache API ermöglichen einen schnellen Entwicklungszyklus. Lambda@Edge erfordert mehr Konfiguration und langsamere Bereitstellungszeiten.
• Lambda@Edge bietet eine granularere Kontrolle mit seinen vier verschiedenen Triggern, mit denen Sie Kosten und Leistung optimieren können, indem Sie Code nur dann ausführen, wenn es absolut notwendig ist (z. B. nur bei Cache-Fehlschlägen).

Die Zukunft des Edge: Was kommt als Nächstes?

Das Frontend Edge Computing steckt noch in den Anfängen, und die Innovation schreitet in rasantem Tempo voran. Der anfängliche Fokus auf zustandslose Berechnungen erweitert sich schnell. Hier sind einige Trends, die die Zukunft prägen:

• Zustand am Edge: Die größte Herausforderung ist die Verwaltung von Zuständen. Dienste wie Cloudflare Workers KV und Durable Objects leisten Pionierarbeit bei der Speicherung von Daten am Edge und ermöglichen so komplexere Anwendungen wie Echtzeit-Chats, kollaborative Dokumente und Warenkörbe, die vollständig im Edge-Netzwerk ausgeführt werden.
• WebAssembly (Wasm): Wasm ermöglicht es Entwicklern, Code, der in Sprachen wie Rust, C++ und Go geschrieben wurde, mit nahezu nativer Geschwindigkeit in einer sicheren Sandbox auszuführen. Dies öffnet die Tür für leistungskritische Aufgaben wie Videoverarbeitung, komplexe Berechnungen und maschinelles Lernen, die am Edge durchgeführt werden können.
• Datenbanken am Edge: Die Replikation und Synchronisierung von Daten über ein globales Netzwerk ist eine massive Herausforderung. Neue Dienste wie Cloudflare's D1 und FaunaDB bauen global verteilte Datenbanken, die nahtlos mit Edge-Funktionen zusammenarbeiten und die Latenz beim Datenzugriff minimieren.
• Edge AI/ML: Da Geräte und Edge-Server immer leistungsfähiger werden, wird die Ausführung von maschinellen Lernmodellen am Edge für Aufgaben wie Personalisierung, Betrugserkennung und Bildanalyse alltäglich werden und intelligente Antworten mit minimaler Verzögerung liefern.

Die richtige Wahl für Ihr Projekt treffen

Die Entscheidung zwischen Cloudflare Workers und AWS Lambda@Edge hängt stark von Ihren spezifischen Anforderungen, Ihrer bestehenden Infrastruktur und Ihren Leistungszielen ab.

Wann Sie sich für Cloudflare Workers entscheiden sollten

• Leistung hat für Sie oberste Priorität. Wenn Sie eine hochgradig interaktive Anwendung erstellen, bei der jede Millisekunde Latenz zählt, sind die nahezu null Kaltstarts von Workers ein entscheidender Vorteil.
• Ihre Logik ist zustandslos oder kann Edge-nativen Zustand verwenden. Workers eignen sich hervorragend für Aufgaben wie Authentifizierung, A/B-Tests und Weiterleitungen. Für den Zustand werden Sie ihr Ökosystem (KV, Durable Objects) verwenden.
• Sie legen Wert auf eine schnelle, moderne Entwicklererfahrung. Wenn Ihr Team schnell mit einem einfachen CLI, schnellen Bereitstellungen und einer Web-Standard-API vorankommen möchte, ist Workers eine ausgezeichnete Wahl.
• Sie bauen ein neues Projekt oder sind nicht an das AWS-Ökosystem gebunden. Es bietet eine leistungsstarke, eigenständige Plattform für den Aufbau global verteilter Anwendungen.

Wann Sie sich für AWS Lambda@Edge entscheiden sollten

• Sie sind stark in das AWS-Ökosystem investiert. Wenn Ihre Infrastruktur, Datenspeicher und CI/CD-Pipelines bereits auf AWS basieren, wird sich Lambda@Edge natürlicher integrieren.
• Sie benötigen eine granulare Kontrolle über den Lebenszyklus von Anfragen. Das Vier-Trigger-Modell ermöglicht eine fein abgestimmte Logik, die Kosten und Ausführung basierend auf dem Cache-Status optimieren kann.
• Ihr Team ist bereits mit AWS Lambda und IAM vertraut. Die Lernkurve wird viel flacher sein, da es auf vorhandenem Wissen aufbaut.
• Ihre Edge-Logik erfordert Node.js-spezifische Module oder komplexere Berechnungen, die die strengeren CPU-Limits von Cloudflare Workers überschreiten könnten.

Fazit: Die Umarmung des Frontend Edge

Frontend Edge Computing ist keine Nischentechnologie mehr; es ist die Zukunft hochleistungsfähiger Webanwendungen. Indem wir Logik von zentralen Servern in ein global verteiltes Netzwerk verlagern, können wir Erlebnisse schaffen, die schneller, sicherer und widerstandsfähiger sind als je zuvor. Cloudflare Workers und AWS Lambda@Edge sind zwei außergewöhnliche Plattformen, die diesen Wandel anführen, jede mit einer einzigartigen architektonischen Philosophie und unterschiedlichen Stärken.

Cloudflare Workers besticht durch seine rohe Geschwindigkeit, die innovative V8 Isolate-Architektur und die hervorragende Entwicklererfahrung, was es zu einer fantastischen Wahl für latenzkritische Anwendungen macht. AWS Lambda@Edge nutzt die schiere Kraft und Breite des AWS-Ökosystems und bietet eine beispiellose Integration und granulare Kontrolle für diejenigen, die bereits in seine Plattform investiert haben.

Als Entwickler oder Architekt ist das Verständnis der Fähigkeiten des Edge heute eine entscheidende Fähigkeit. Es eröffnet die Möglichkeit, langjährige Leistungsengpässe zu lösen und eine neue Klasse von wirklich globalen, sofort reaktionsfähigen Anwendungen zu erstellen. Der Edge ist nicht nur ein neuer Ort, um Code bereitzustellen – es ist eine neue Art, über das Bauen für das Web nachzudenken.